The next step is to define exactly what information we require for each one.
Each Asset Information Requirement (AIR) entry should follow a clear and consistent structure, this ensures our delivery team knows what to provide, how to provide it, and when.
When we define an AIR for an asset, we typically include the following elements:
| Field | Description |
|---|---|
| Asset Type | The name of the asset (e.g. Chiller, Fire Alarm Panel, Fan Coil Unit) |
| Property / Data Field | What information we require (e.g. Serial Number, Fire Rating, Installation Date) |
| Purpose / Use Case | Why this information is needed (e.g. for warranty tracking or compliance) |
| Units / Format | Expected unit or format (e.g. °C, kW, YYYY-MM-DD) |
| Delivery Stage | When we expect certain data to be delivered (e.g. prior to commissioning, at handover) |
| Responsibility | Who is expected to provide or verify the data (e.g. Contractor, MEP Consultant) |
| Verification Rule | How the data will be checked (e.g. required field, format check, value range) |
| Standard Mapping | If applicable, map to COBie field or IFC property set (e.g. Pset_ManufacturerTypeInformation) |
| Notes / Clarifications | Any special conditions, references to standards, or clarifications |
Clearly defining asset information requirements ensures that operational data is requested with purpose. By focusing on the information that supports real operational outcomes, teams avoid unnecessary data collection and create a strong foundation for structured information delivery later.